home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1072 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.3 KB
  1. From: wald@theory.lcs.mit.edu (David Wald)
  2. Message-ID: <WALD.96Apr12143619@woodpecker.lcs.mit.edu>
  3. X-Original-Date: 12 Apr 1996 18:36:19 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 14 Apr 96 11:50:59 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Draft Std. C++ Preprocessor
  9. Organization: Theory of Computation, LCS, MIT
  10. References: <mike_duigou-0804961108400001@news.aimnet.com>
  11.     <4klsr0$ii4@engnews1.Eng.Sun.COM>
  12. In-Reply-To: clamage@Eng.Sun.COM's message of 12 Apr 96 16:25:37 GMT
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMXDmxuEDnX0m9pzZAQFJkgF/RRGKOqw2lByK8XiwrGmnf3ZAJa0Ey2Vk
  15.     4HYvLVwDdGxL/g2DeuQ4swekulEZlZZt
  16.     =490h
  17.  
  18. In article <4klsr0$ii4@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM
  19. (Steve Clamage) writes:
  20. >In article 0804961108400001@news.aimnet.com, mike_duigou@fwb.com
  21. >(Mike Duigou) writes:
  22. >>One change I was hoping for was the inclusion of a non-fatal
  23. >>"#warning" directive to match the fatal '#error" directive.  (hey,
  24. >>the compiler can make both errors and warnings, why can't I?). As
  25. >>you probably know, a number of compilers support the #warning
  26. >>directive.
  27. >
  28. >We've been through this discussion many times. The #error directive isn't
  29. >required to be fatal. All that is required is that it cause a message to
  30. >be emitted. It is difficult to specify "fatal" versus "non-fatal" in a
  31. >system-independent way.
  32.  
  33. So don't specify it.  I've seen the discussion go around a few times,
  34. but I can't say I've ever understood the objection to requiring
  35. #warning in the standard and letting the distinction be
  36. implementation-defined.  The fact that there isn't a useful
  37. distinction in some environments doesn't diminish the usefulness of a
  38. #warning directive in the large number of environments which *do*
  39. support such a distinction.  This wouldn't be the first item in
  40. the standard that could be more usefully implemented in some
  41. environments than in others.
  42.  
  43. >Adding non-standard directives like #warning is not very programmer-
  44. >friendly.
  45.  
  46. Right; that's why it should not be non-standard.  As a non-standard
  47. extension it's of fairly limited utility.  As a standard feature, it
  48. would be useful in many environments, and particularly useful when
  49. you're porting code to a new environment -- i.e., when the code you're
  50. porting by definition can't have any compiler-specific #pragmas
  51. available.  Its utility would lie in its portability; all compilers
  52. would accept it, and the worst they'd do would be to behave exactly as
  53. if they'd seen an #error.  Many compilers would do better than that.
  54. The problem is that there is now no portable way to hint to the
  55. compiler that it may as well go on processing after a particular
  56. #error, even though the compiler is permitted to do so.
  57.  
  58. -David
  59. -- 
  60. ============================================================================
  61. David Wald      http://theory.lcs.mit.edu/~wald/     wald@theory.lcs.mit.edu
  62. ============================================================================
  63. ---
  64. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  65. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  66. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  67. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  68. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  69.